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[Declaration of John Doulamis| 



I, John Doulamis, being over the age of eighteen and competent to testify, make the following 
declaration: 



1. I hold a bachelor's degree in Information Technology from University of Athens, Greece 
and a Master of Science in Computer Science (M.Sc.) from The American University, 
Washington D.C. My educational background in information technology and computer 
science, and my experience working with trading systems, has given me knowledge and 
expertise in the field of securities trade automation - a field that almost exclusively 
involves computer-based automation and communication software and hardware. I know 
well the software and hardware used by trading systems to accomplish trade automation, 
and have a detailed and expert understanding of the requirements and constraints placed 
on these systems by traders, portfolio managers and other financial services providers. 



2. From 1996 to 2008, 1 worked for Macgregor and Investment Technology Group (ITG), 
the well-known global trading technology company. Both companies specialize in order 
management systems for the securities industry. From 1996 to 2006 I held various 
positions in the Software Development department at Macgregor, essentially covering the 
entire range from Junior Developer to Vice President of Software Development. I have 
over 12 years experience in the securities trading business, and have substantial expertise 
in financial technology and the firms that use such technology. 
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3. From 2006 to 2008, 1 was a full-time consultant for the Research and Development group 
at ITG. During my tenure at Macgregor and ITG, I became intimately familiar with 
Order Management Systems - which constituted the companies' business nucleus - as 
well as most of the software systems that surround and accompany an OMS (portfolio 
management, research/analysis, live pricing, execution links, compliance etc). I acquired 
a well-rounded knowledge of the entire spectrum of such systems along with their 
interactions, by performing various tasks such as: 

a. Hands-on development of core OMS features 

b. Second-level technical support of customer issues (bug fixing) 

c. Application integration between OMS and other software systems at various 
levels (Data level, Functional level, Presentation level) 

d. Design of new features and Product Roadmap management 



4. I am very familiar with the order management systems (OMS) available in May 1999, 
when the Shaw et al. patent was first applied for. 



5. I have thoroughly analyzed the Shaw et al. patent application, as well as the SEC 
reference and LimiTrader system discussed therein. 



6. I am absolutely certain that as a development team, we would have considered the 
integration of the LimiTrader system with an OMS impossible in May 1999, and 
certainly not obvious. An effort like that would have been deemed infeasible and 
meaningless, for many reasons including the following: 



7. OMS users demand a single and responsive interface that supports the full trading 
process, including communications among internal parties such as portfolio managers, 
traders and compliance officers, and external parties such as brokers, execution systems, 
settlements systems, and market data providers. Providing such an interface to 
LimiTrader would not have been possible without a substantial redesign and rewrite of 
the LimiTrader system - making integration with an OMS not only impractical, but 
unthinkable. 

8. To satisfy the demands of OMS users, OMS providers invest substantial resources to 
support and integrate all the trading functions and systems required to fully automate and 
speed up the life cycle of a trade. Integration of these real-time workflow systems is a 
very complex undertaking. For integration to be successful, it must be achieved at 
multiple levels: starting with the database and data models that provide a common 
platform for robust semantic interchange across systems, continuing at the messaging and 
service levels that allow systems to cooperate and synchronize their functionality and 
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complete a business transaction or sub-process, and ending with a single user interface to 
eliminate the need and risks of duplicate data entry, and the confusion associated with 
distinct interface standards. OMS providers have had to develop most of this 
functionality from scratch, in order to ensure that all elements at each of these levels are 
tightly and correctly integrated in real-time. 



9. Systems designed in the early 1990s, such as LimiTrader, did not anticipate a future in 
which computer technology would allow for independently developed systems to share 
resources and cooperate in real-time. Closed system design was the prevailing model for 
trading system architecture throughout the early 1990s. Systems were envisioned to be 
stand-alone entities, and only interface with external systems through batch-oriented file 
based import/export utilities. LimiTrader is a shining example of such closed system 
design. 



10. If someone had asked our company in 1999 to integrate an OMS with the LimiTrader 
system, we would have replied that such an integration was not feasible, much less 
obvious , because LimiTrader was a closed system and was not designed to be integrated 
with external systems. And this situation was not uncommon - often, customers would 
request that an OMS be integrated with a proprietary or 3 rd party legacy trading system, 
and we would have to reply that integration was not possible because the trading system 
was designed as a closed system (as LimiTrader was). 



1 1 . The LimiTrader design, the norm at the time, was simply not designed to be integrated 
with an OMS. It lacks all the critical elements required for it to be integrated with an 
OMS, or any other real-time trading workflow system. It does not have an 'open' 
architecture, for example one built around a SQL Relational database that would allow 
other systems to access and modify business data in a transactionally robust manner. It 
also does not have a "real-time" system architecture, which can support event-driven 
message based integration across systems. It does not have the ability to publish events 
or provide a transactionally-safe, service-oriented application program interface (API), 
both of which are important technical requirements for a trading system which will be 
integrated with an OMS. Further, the LimiTrader system does not include support for 
critical business functions such as block trading, 24 hour trading or international trading. 
Without this support, integrating LimiTrader with an OMS would have been impossible, 
because an OMS does provide these critical business functions. 



12. Moreover, the dial-up system used by LimiTrader to communicate with parties would be 
inadequate to support the equity trading decisions and workflows from the OMS. And 
the lack of a real-time API would require a user to go to the LimiTrader terminal just to 
cancel an order, adding unacceptable delays. 
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13. Further, LimiTrader' s non-secure matching approach is not suited for the OMS market. 
One of the main benefits of an OMS is that it allows users to retain control of their 
orders until the last possible moment. Equity traders, the majority of OMS users, are 
extremely wary of letting any outside parties learn the contents of their order book. They 
know that any information about their intention to buy or sell shares in the near future 
can be exploited by 3 rd parties to take advantage of them. They use the OMS as a 
platform for quickly directing and redirecting their orders across any and all liquidity 
sources. It is unthinkable that OMS traders would direct any order flow into a matching 
system such as LimiTrader that notifies multiple parties of possible matches. OMS 
traders would require that they be immediately and simultaneously notified of any 
match, and that only one match be proposed at a time. LimiTrader was not designed to 
support this requirement. Actually, LimiTrader seems to have been designed for a 
market where information leakage is not a great concern, and where participants expect 
and accept that market information will propagate in several minutes rather than in a 
couple of seconds. 



14. There are also a number of other LimiTrader features that clearly point to a system not 
compatible with OMS integration. For instance, an initial capacity for 50 simultaneous 
users is at least a couple of orders of magnitude lower than what is required to support 
actual usage with an integrated OMS. Similarly, LimiTrader' s 30-minute backup 
recovery capability would be unacceptable to the OMS market. Most organizations would 
demand a hot backup to guarantee uninterrupted access. It would be unthinkable for an 
equity trader to have orders in the LimitTrader system in an uncertain state for up to 30 
minutes, because the trader would always be wondering: Did I miss a match? Was the 
order executed? What is my current cash position? It is critical to have such information 
immediately available at all times - and with LimiTrader, it would not be. 



15. In addition, the OMS's in existence as of May 1999 were simply not configured for the 
features described in the SEC reference - i.e., non-automated bid or offer advice and 
market information - nor were they capable of handling such features without prior 
modification to the OMS. Examples of these OMS's, which existed in May 1999 and 
which were not configured to offer non-automated bid or offer advice and market 
information, include the Landmark system from The Long View Group, the Predator 
system from Macgregor, and the Charles River IMS system from Charles River 
Development. 



A ppn. Number 10/032.535 



(Shaw. John) 



GAU3696 



Declaration of John Doulamis 



5 



16. Thus, users could not have obtained these features via an OMS in existence in May 1999 
and integrated with a central matching system. The features would have been cut off 
unless the OMS had itself been modified before integrating it with the central system - 
and this would not have been obvious, because these OMS's are separately-owned and 
not freely modifiable. In other words, to retain LimiTrader's individualized features, one 
would have had to first modify the OMS, then also modify the LimiTrader system by 
grafting the OMS onto it. This kind of double, sequential modification would simply not 
have been obvious at the time of the Shaw et al. patent application. 



17. Moreover, trying to make an OMS function via LimiTrader's existing dial-up system, 
over standard phone lines, would not be satisfactory. Standard phone lines simply do not 
have the capacity to handle the communication volume associated with a commercial 
trading environment, nor would such a configuration have the necessary communication 
speed. For these reasons, trying to use LimiTrader's existing dial-up system to handle 
order inputs from an OMS would render the LimiTrader system sub-optimal and slow. 



18. Further, a configuration in which orders were received from individuals into the central 
system via an OMS, with a dial-up system "on the side" wherein the individuals placing 
orders via the OMS would dial into the central system to receive non-automated 
assistance would not be workable or economically viable, because a configuration like 
that would entail unnecessary duplication of the contact interface between order placers 
and the central system (i.e., place orders using one interface, but do everything else using 
another, completely separate interface). Such duplicate interfaces would require constant 
communication and reconciliation to ensure that information received from, and provided 
to, an order-placer via one contact interface matched information received from, and 
provided to, an order-placer via the other contact interface. Multiple interfaces are more 
expensive to operate and carry the risk of mismatched, inconsistent data 



The undersigned being hereby warned that willful false statements and the like are 
punishable by fine or imprisonment, or both, under 18 U.S.C. §1001, and that such willful 
false statements and the like may jeopardize the validity of this document, declares that all 
statements made of his own knowledge are true and that all statements made on information 
and belief are believed to be true. 





Date 



